fix(docs): correct model capability field names and web-search examples - #86
Merged
hMED22 merged 3 commits intoJul 28, 2026
Conversation
The /v3/models capabilities object was documented with field names that do not exist (pdf/reasoning/web_search/tool_calling); the API returns supports_* keys. Filtering on the documented names silently matches nothing, so the documented "find web-search models" workflow could never work. - Document the real capability fields (supports_web_search, supports_reasoning, supports_function_calling, input_modalities, ...) and replace the invented response example with a real API entry - Fix the supported-models instruction to filter on capabilities.supports_web_search, with a tested snippet that fails on future field-name drift - Switch web-search examples from openai/gpt-5.2 (200 but no search) and openai/gpt-4o (400) to google/gemini-flash-latest — a stable alias, so no hardcoded model version - Document that regular OpenAI models only support web search via the Responses API; on chat completions only the dedicated search variants perform searches - Fix the stale capabilities object in the EU endpoint example
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
WalkthroughThe documentation updates expand model capability schemas, catalog response examples, alias guidance, and web-search instructions. Examples now use updated capability fields, richer model metadata, and ChangesModel capability documentation
Estimated code review effort: 3 (Moderate) | ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@v3/llms/listing-models.mdx`:
- Around line 124-137: Add `supports_native_streaming` and
`supports_embedding_image_input` to the standard capability-fields table in the
model listing documentation, with concise descriptions matching the response
example and existing field style. Keep the provider-specific-key guidance
unchanged.
In `@v3/llms/web-search.mdx`:
- Around line 113-117: Update the web_search_models comprehension to safely
handle capability objects missing supports_web_search, treating those models as
unsupported rather than raising KeyError. Preserve inclusion only for models
with non-null capabilities that explicitly enable supports_web_search.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: a346d006-5316-4799-b587-62f2d65e6d9d
📒 Files selected for processing (3)
v3/data-governance/eu-endpoint.mdxv3/llms/listing-models.mdxv3/llms/web-search.mdx
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
- Document supports_native_streaming and supports_embedding_image_input, completing the table against the response example - Make the web-search filter snippet tolerate sparse capability objects, matching the documented "missing key means unsupported" guidance - Spelling and punctuation cleanups
The /v3/models endpoint is public, so the samples no longer send an Authorization header (the EU-endpoint page already called it bare). Also point the web-search supported-models section at the visual model catalog, which supports filtering by capability.
hMED22
deleted the
ahmednemdil/eng-70-docs-model-capability-field-names-are-all-wrong-and-web
branch
July 28, 2026 17:10
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes ENG-70.
Problem
The
/v3/modelscapabilitiesobject was documented with field names that don't exist (pdf/reasoning/web_search/tool_calling); the API returnssupports_*keys. Filtering on the documented names silently matches nothing: the documented "find models wherecapabilities.web_searchis true" workflow reported 0 of 820 models. On top of that, two of the three web-search examples used models that fail (openai/gpt-5.2returns 200 but performs no search while billing;openai/gpt-4oreturns 400).Changes
v3/llms/listing-models.mdxsupports_web_search,supports_reasoning,supports_function_calling,input_modalities, ...), verified against the live API (820 models), plus a note about sparse provider-specific keys and"capabilities": nullgoogle/gemini-flash-latestentry from the API, which also demonstrates a populatedalias_offield*-latestaliases and explainalias_ofv3/llms/web-search.mdxcapabilities.supports_web_search, with a tested Python snippet that tolerates sparse capability objects (guarding against this class of field-name drift remains with ENG-23)google/gemini-flash-latest: the working Gemini family, via a stable alias so no hardcoded version (verified present on prod and staging withsupports_web_search: true)openai/gpt-4o-search-preview,openai/gpt-5-search-api) perform searchesv3/data-governance/eu-endpoint.mdxOut of scope
Which models actually perform searches (vs. advertise it: the API still returns
supports_web_search: trueforopenai/gpt-4o, which 400s) is ENG-69; the docs deliberately avoid enumerating models so nothing here depends on that fix.🤖 Generated with Claude Code
Summary by CodeRabbit